PWAs sind typischerweise installierbar und offline nutzbar, sie können Push-Benachrichtigungen empfangen und kommen ohne nativen Container aus. Um das zu erreichen, setzen PWAs auf bewährte, aber dennoch aktuelle Technologien wie HTML5, CSS3 und JavaScript. Mit Hans-Christian Otto, Trainer auf den JavaScript Days 2017, haben wir uns über Progressive Web-Apps unterhalten und ihn zum Streit PWAs vs Native Apps befragt. Außerdem gibt er uns Einblicke in die Entwicklung von PWAs mit React und erläutert das Thema Sicherheit im Bezug auf PWAs.

Christian, der Streit um die Vor- und Nachteile von Progressive Web-Apps bzw. Native wird seit vielen Jahren ausgetragen. Ist aus deiner Sicht „Progressive Web Apps vs. Native“ aber überhaupt noch die richtige Fragestellung?

Hans-Christian Otto: Es ist kompliziert. Ich finde, die Frage kann man schon noch stellen. Muss man in manchen Fällen vielleicht sogar. Ich versuche meistens, insbesondere die Technologien, die ich selbst einsetze, kritisch zu hinterfragen, um nicht von Problemen überrascht zu werden. Entsprechend differenziert betrachte ich PWAs auch.

Und man muss leider sagen, dass es in der heutigen Zeit immer noch Situationen gibt, wo PWAs kein Ersatz sind für Native Apps. Zum einen ist da natürlich iOS – auf iOS gibt es bis heute nur eingeschränkten Support für PWAs. Glücklicherweise gibt es seit vergangener Woche deutliche Anzeichen, dass Apple mit der Entwicklung von Service Workern für iOS begonnen hat.
Aber auch unter Android können PWAs noch nicht alle Funktionen abdecken, die eine Native App abdecken kann. Ich denke, die Beispiele sind hinreichend bekannt, aber insbesondere der Zugriff auf Adressbuch und Kalender sowie die ein oder andere Hardware ist bis heute aus dem Web nicht möglich.

Ich finde, in unserer Branche geht es oft darum, den richtigen Kompromiss zu finden zwischen “Wirtschaftlichkeit” und “Perfektion”. Und ich denke, da passen PWAs perfekt rein. Wer das Budget hat, separate Apps für Desktop, iOS und Android zu bauen, für den kann es Sinn ergeben. Denn auch, wenn eine PWA auf allen Plattformen “funktioniert”, so ist sie noch lange nicht perfekt für alle Plattformen. Die UX unter iOS und Android unterscheidet sich an vielen Stellen dann doch noch mal ziemlich. Entscheidet man sich für eine PWA, so hat man auf jeden Fall sehr schnell ein MVP für alle Plattformen, und kann die unterschiedliche UX dann als i-Tüpfelchen noch draufsetzen. Bei Nativen Apps muss man nun mal alle drei Anwendungen so oder so von Grund auf separat entwickeln. Die richtige UX für die entsprechende Plattform ist also nicht mit erheblichen Mehrkosten verbunden.

Zu guter Letzt gibt es noch einen nicht-technischen Punkt, den man nicht außer Acht lassen sollte: Es gibt Momente, wo ein Stakeholder sagt: “Wir müssen im App Store vertreten sein, unser Wettbewerb ist da auch!”. Glücklicherweise gibt es ja auch heute noch Cordova, so dass man seine PWA auch problemlos dahin bekommt.

Mein Fazit sieht also so aus, dass es Situationen gibt, wo eine PWA auch heute noch kein gangbarer Weg ist. Deswegen sollte man sich am Anfang die Frage stellen: “Wie ist die Vision unseres Produktes? Brauchen wir Funktionalitäten, die mittels Web-Technologien nicht umsetzbar ist?” Dann sollte man vermutlich noch den nativen Weg gehen, ansonsten wäre meistens vermutlich die PWA der effizientere Weg.

Was begeistert dich persönlich am meisten an Progressive Web-Apps?

Hans-Christian Otto: Auch wenn ich eben durchaus kritisch gesprochen habe, bin ich ein großer Verfechter von Technologien. Ich habe schon vor zehn Jahren Rich Internet Applications mit JavaScript gebaut, damals insbesondere mit Ext JS. Seitdem stelle ich immer wieder die Frage, wofür wir eigentlich noch Desktop-Anwendungen brauchen. Seit dem ersten iPhone, dass ohne App Store kam, und wo die einzige Möglichkeit war, eigene Anwendungen auf dem iPhone auszuführen das Web war, ist klar, dass dieser Trend auch auf Smartphones übergegriffen hat.

Seit einigen Jahren setze ich mich zunehmend für die Offline-First Bewegung ein. Und dass heutzutage, wo viele Native Apps nicht funktionieren, sobald man offline ist, das Mobile Web sich zunehmend dahin bewegt, offline zu funktionieren, macht mich unfassbar glücklich.

In deinem Workshop „Wir bauen eine Progressive Web-App“ auf den React Days begleitest du zusammen mit Elmar Burke die Teilnehmer beim Bau einer React-Anwendung. Was sind die wichtigsten Überlegungen, die man vor der Entwicklung einer React-Applikation anstellen sollte?

Hans-Christian Otto: Man sollte sich vor allen Dingen über eines im Klaren sein: React ist kein Framework. React ist eigentlich eine relativ kleine Bibliothek, um ein DOM zu rendern.
Das ist ein wichtiger Unterschied zu z.B. Angular. Angular kommt, wie man so schön sagt, als “batteries included”-Technologie daher. Die Batterien sind enthalten. Man kann also sofort loslegen zu spielen.
Wenn man eine etwas größere Anwendung mit React baut, muss man noch viele weitere Entscheidungen treffen, als einfach nur zu sagen “Ich mache jetzt React!”. Man muss sich entscheiden, wie man seine Anwendung strukturiert. Wo wird der Zustand der Anwendung gehalten? Setzt man auf Flux? Oder lieber Redux? Oder doch mobx? Oder baut man sich das “mal eben schnell” mit rxjs selbst? Möchte man auf Webpack setzen? Oder doch lieber SystemJS?
All das kann man in React beliebig zusammenstecken. Das finde ich super. Das heißt aber auch, man muss sich wirklich mit dem Ökosystem beschäftigen. React kann man in wenigen Stunden verstehen. Redux auch. Bis man wirklich fit darin ist, eine Anwendung mit React und Redux zu bauen, vergehen aber eher Tage. Bei Angular ist das alles schon mal vorgegeben, auch wenn alle Komponenten getauscht werden können.
Ich selber bin mittlerweile ein großer Fan der Kombination create-react-app, React, Redux und TypeScript.

Hierzulande immer ein wichtiges Thema: Wie steht es um die Sicherheit von Progressive Web-Apps, gerade dann, wenn auch sensible Daten darin Verwendung finden?

Hans-Christian Otto: Natürlich ist es erst einmal so, dass die Daten einer PWA irgendwo im Speicher des Browsers liegen und dort verhältnismäßig schlecht geschützt sind. Bei Native Apps ist es typischerweise so, dass Apps, deren Daten besonders schützenswert sind, nach einem Kennwort oder einem Fingerabdruck fragen und die Daten verschlüsseln. Der Zugriff auf den Fingerabdrucksensor ist für Web-Anwendungen noch nicht möglich, wir müssen also wieder ein Kennwort verwenden. Ist dieses Kennwort sicher genug, so kann man es natürlich zum Verschlüsseln der Daten verwenden. Die Bibliothek PouchDB bietet beispielsweise mit einem Plug-In eine einfache Möglichkeit, die in PouchDB gespeicherten Daten zu verschlüsseln.

Allerdings muss man auch dazu sagen, dass es deutlich einfacher ist, den einen Debugger an eine Mobile Seite anzuhängen, die man geöffnet hat, als an eine Native App eines Drittentwicklers. Und wenn man erstmal den WebInspector offen hat, kann man natürlich viele Informationen aus einer PWA extrahieren.

Auf der anderen Seite: Wie viele native Apps sind denn mit einem Kennwort verschlüsselt? Die wenigsten, denn das stört ja auch die UX. Und das bedeutet, auch die Daten der nativen Apps sind meist nur durch einen vierstelligen Zahlencode oder ein kleines Wischmuster geschützt. Einen Passwort-Manager würde ich in der heutigen Zeit insofern lieber als Native App sehen.

Trügt der Eindruck oder performen Progressive Web-Apps nicht so gut auf iOS-Devices?

Hans-Christian Otto: Ich bin unschlüssig. Man muss natürlich sagen, dass die PWAs auf iOS einfach noch nicht soweit sind. Solange wir noch nicht die erwähnten Service Worker haben, braucht man natürlich noch so etwas wie App Cache Manifests.
Einige Zeit war es auf iOS auch so, dass die Apps, die man zum Homescreen hinzugefügt hat, eine langsamere Browser-Engine hatten. Ich glaube, ohne mir ganz sicher zu sein, diese Zeiten sind vorbei.
Ich habe viele Web-Apps auf iOS gesehen, die wirklich gut performt haben. Ich habe aber noch mehr gesehen, deren Performance zu wünschen übrig lässt. Das gleiche gilt allerdings auch für Native Apps. Man kann bei beidem etwas falsch machen.

Geschrieben von: Christoph Ebert

Christoph Ebert stieß im Juli 2011 zum Redaktionsteam von Software & Support Media und verantwortet als Team Lead die entwickler-Redaktion. Davor betreute er die Portale webmagazin.de, createordie.de und mobile360.de. Vor seiner Zeit in Frankfurt arbeitete der studierte Amerikanist und Tech-Geek als Redakteur für das Heimkinofachmagazin audiovision.